Fix vnode event move #257
Fix vnode event move #257
Conversation
…node after diffing
|
Are you sure that solves all issues without introducing new ones? I remember older versions doing that and only shifting the problems around. I've since then become delusional about virtual DOMs and DOM diffing altogether, it's all just a big abstraction inversion and will never work reliably. :-( |
No, I'm not. But the tests pass and it seems to work with the manual testing I've done
Any pointers for where to look on this? I can't find anything in the git/issue history
Perhaps, but Karax is the most developed Nim webapp library so it would be nice to keep it going. Receiving vnodes in event handlers is a part of the public API, so we should either fix it or deprecate and offer only I'd be curious to hear your thoughts on vdom/diffing and what you would do now instead. Signal based reactivity (and no vdom) is popular now, but maybe there's something better out there. |
Ok. |
My later attempt was "Knete", Karax's DSL for producing the real DOM. Inside event handlers you then mutate the real DOM directly. It's much more annoying to use for "todo app", but I'd probably use it over the current Karax. Best Interop with the rest of the DOM ecosystem and all of its widgets etc plus you're unlikely to run into catastrophic performance problems. The underlying problem is that of state duplication. You have the "raw" data which is then replicated in the UI (and enriched via styling etc) which can cause all these synchronization bugs that DOM diffing wipes away. But this problem might also be solvable by an API that extracts the data again from the UI state. Also, usually you have some duplicated state inherently as during input you want to do validation before committing it. |
This PR adds a
reapplyEventsproc (called duringmoveDom) that removes event handlers from the attached dom element, then reapplies them pointing to the new vnode. This is necessary because after diffing the new vnode now owns the attached dom element.This approach feels a little costly as the handlers must be replaced on each diff. I initially tried to instead attach the vdom to the dom node so that the event wrapper could use that, and the vnode could be updated, but that did not work. What are your thoughts @Araq?
This would solve #254 and #117